怎样实现多人协同编辑

    相信大家都用过office，那么譬如你做了一个word之后，另一个人想要修改怎么办。目前的做法都是将这个文件保存，然后再打开进行修改，因为你打开这个文件之后，其他地方打开这个文件只能显示只读模式。这种模式可以理解为，一人占一坑，你进去了，别人进不来。。。。。。

    世上本没有路，走的人多了，也就成了路。老是保存，打开，保存，打开，还只能两人搁那儿套娃，有人就提出能不能多人一起编辑呢，答案是肯定的，博主在度娘上搜索的时候发现了永中的weboffice，在测试的时候，效果还可以。那么本文的目的是什么，当然不是讲解整个一套office协同编辑，只是拎着重点讲解一下协同编辑的难点和怎么实现。

    一开始想的难点有数据变化，数据冲突，数据更新，但是思考了一番，个人认为数据变化好像不算是难点，开始想的是如果有三个字母ABC，在ABC的AB中插入一个D字母，那么就变成了ADBC，可要考虑到文本换行，翻页的问题，但是仔细一想，这些东西以前一坑一人的模式其实已经解决了，怎么将数据保存对于协同编辑无关紧要。

    那么难点来到了这么处理数据冲突这一块，同样的ABC，小明编辑的时候是改成A小明BC，小红编辑的时候改成A小红BC，那么最后保存到数据库的数据是什么呢，同样在编辑完后，在小明和小红的客户端会显示什么呢？这就是在线编辑产生冲突的情况。

    以上面小明小红的案例举例，看下两位小朋友同时编辑发生甚么事情了。我们假定小明同学发动技能，先人一步，手速比较快，先提交了数据，那么按照理论来讲最后正确的数据应该是A小明小红BC，因为小红编辑完后，本地已经是A小红BC，但是过了一会儿，后台告诉小红的客户端小明也编辑了，实在AB中留下了小明的痕迹，因此小红这边执行了这个行为，所以最后变成了A小明小红BC。

    其实在真实的场景中，可能是小明，小红，小李，小王很多很多小朋友在一起编辑，那么这些复杂的逻辑是怎么解决呢？

小明：

    小明编辑完本地已经是A小明BC，过了一会儿，后台告诉小明小红也编辑了，编辑的行为就是在小明的后面增加小红，那么最终小明的本地显示的结果为A小明小红BC。

小红：

    小红编辑完本地已经是A小红BC，过了一会儿，后台告诉小红小明也编辑了，编辑的行为就是在小红的前面增加小明，那么最终小红的本地显示的结果为A小明小红BC。

    总而言之，就是将两者的方案在后台处理变成一致后再传给客户端。

    那么后台发生什么了，怎么就能处理成一样了，让我们来揭开这个盲盒，OT算法目前是yozo weboffice中所采用的的方案，因此是经过验证的，值得研究。最开始，看到github上源码的时候看起来很复杂，后来经过一些大佬值点后，发现还是很复杂......,所以博主就简单的说明下。

    首先，我们将文本内容修改转成以下三种类型的操作：

提取这些操作可以通过Levenshtein distance算法来实现，如果小红同时编辑AB变成A小红，那么小红执行所产生的步骤为：

    如果我们应用小明的操作，将字符串变成B小明，然后再应用小红的操作的时候，发现保持第一个字符之后，发现不能detele("B")了，这时候需要转换小红的操作来适应新的字符串，譬如变成这样：

    OT算法的核心其实也就是转换算法，这个思路就是将编辑转成操作，如果有一堆小朋友在操作的同时，需要将一堆操作进行转换，具体怎么转换是可以按照几级逻辑去设定，譬如数据先提交服务器的先进行操作，或者也可以后提交服务器的先进行操作。

    好像这么一说也就几百字，OT算法听起来挺简单的，其实是坐井观天，我也曾经是那个小青蛙，国外的大佬说了他工作n年，也没人总结出一个最好的方法。因为上面举的例子就是小红和小明的二人互动，如果还有小李，老王呢，如果每个人编辑了多次，编辑的过程中还有网络延迟呢？这些都是用到了分布式的OT算法，是不是觉得这些情况听上去就很复杂。。。。。。

    上面说了别人集毕生精力研究OT算法都可能不太完美，那么如果像博主这种小菜鸡怎么快读作出一个协同编辑出来呢，一句话：拿来吧你！，我们可以不需要研究算法过于深入，就像市场上那么多插件，你难道要每个都亲自去实现吗。自己做做简单的demo的话，博主推荐一个开源库changesets，我们只需要充当小红小明的角色，把转换操作丢给它 ，然后获得最终的结果就行了。

    Rome wasn't built in a day，协同编辑还有许许多多的细节和小难点，譬如客户端之间接受编辑操作的信息，是使用长连接还是websocket，预知后事如何，请听下回分解.........